Thanks for the review! I’ve reconsidered the splitting rules for transforms and reworked the implementation accordingly.

Changes

1. Cached splitOnWhitespace() in a local variable to avoid repeated calls in the loop.
2. Introduced a lastSplitWasWhiteSpace flag and adjusted the splitting logic so that:
   • Empty entries created by consecutive non‑whitespace separators are preserved (e.g. "1,,1" with SeparatorMode.COMMA_ONLY now produces ["1", "", "1"] ).
   • Only the “whitespace immediately followed by a separator” case avoids creating an extra empty token (e.g. "(-1 , 1)" no longer produces a spurious empty element).
     Verification

• Added two focused test cases in AttributeParserTest and confirmed they pass.

Looking better now. I just pushed some tests which I would like the NumberListSplitter to pass.

Thank you for your patience in providing test cases!

Changes:

• Added the trimTokens state: enabled when splitOnWhitespace is true and the splitter is NumberListSplitter. Calls the .trim() method.
• This handles various cases like trimming " 1" to "1".

Validation:

• All test cases in testNumberSplitter have passed successfully.

I don't think this should depend in the splitter being a NumberListSplitter but instead just on splitOnWhitespace. Ideally I would like to avoid having to call .trim(). We should be able to correctly determine the right offsets when creating the substring in the first place.